Intermediate window results in a streaming environment

ABSTRACT

A stream computing application may receive a stream of tuples to be processed by a plurality of stream operators. A first stream operator may receive a data stream, and the first stream operator may be configured to accumulate the data stream according to a window before performing one or more operations and transmitting tuples to a second stream operator. The second stream operator may request that the first stream operator send out tuples before the first stream operator&#39;s window has terminated. In response, the first stream operator may perform its operations on the tuples that it had accumulated before the request came in and then transmit a group of tuples with the intermediate results to the second stream operator.

BACKGROUND

The present disclosure relates generally to the field of streamcomputing, and more particularly to computing applications that receivestreaming data and process the data as it is received.

Database systems are typically configured to separate the process ofstoring data from accessing, manipulating, or using data stored in adatabase. More specifically, database systems use a model in which datais first stored and indexed in a memory before subsequent querying andanalysis. In general, database systems may not be well suited forperforming real-time processing and analyzing streaming data. Inparticular, database systems may be unable to store, index, and analyzelarge amounts of streaming data efficiently or in real time.

SUMMARY

Embodiments of the disclosure provide a method, system, and computerprogram product for processing data. The method, system, and computerprogram product receive two or more tuples to be processed by aplurality of processing elements operating on one or more computerprocessors.

Embodiments of the present disclosure include a method for sendingintermediate results before the termination of a stream operator'swindow. A stream computing application may receive a stream of tuples tobe processed by a plurality of stream operators. A first stream operatormay receive a data stream, and the first stream operator may beconfigured to accumulate the data stream according to a window beforeperforming one or more operations and transmitting tuples to a secondstream operator. The second stream operator may request that the firststream operator send out tuples before the first stream operator'swindow has terminated. In response, the first stream operator mayperform its operations on the tuples that it had accumulated before therequest came in and then transmit a group of tuples with theintermediate results to the second stream operator. Additionalembodiments of the present disclosure are directed to a system and acomputer program product for sending intermediate results in a streamcomputing environment.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings included in the present application are incorporated into,and form part of, the specification. They illustrate embodiments of thepresent invention and, along with the description, serve to explain theprinciples of the invention. The drawings are only illustrative oftypical embodiments of the invention and do not limit the invention.

FIG. 1 illustrates a computing infrastructure configured to execute astream computing application, according to various embodiments.

FIG. 2 illustrates a more detailed view of a compute node of FIG. 1,according to various embodiments.

FIG. 3 illustrates a more detailed view of the management system of FIG.1, according to various embodiments.

FIG. 4 illustrates a more detailed view of the development system ofFIG. 1, according to various embodiments.

FIG. 5 illustrates an operator graph for a stream computing application,according to various embodiments.

FIG. 6A illustrates an example of an operator graph of a streamcomputing application in which illustrative embodiments of the presentdisclosure may be implemented.

FIG. 6B illustrates an example table depicting tuple data that may beaccumulated by an operator, in accordance with embodiments of thepresent disclosure.

FIG. 7 is a flowchart illustrating a method for transmittingintermediate results, in accordance with embodiments of the presentdisclosure.

DETAILED DESCRIPTION

The present disclosure relates to stream computing, and in particular,to computing applications that receive streaming data and process thedata as it is received. While the present disclosure is not necessarilylimited to such applications, various aspects of the disclosure may beappreciated through a discussion of various examples using this context.

Stream-based computing and stream-based database computing are emergingas a developing technology for database systems. Products are availablewhich allow users to create applications that process and querystreaming data before it reaches a database file. With this emergingtechnology, users can specify processing logic to apply to inbound datarecords while they are “in flight,” with the results available in a veryshort amount of time, often in fractions of a second. Constructing anapplication using this type of processing has opened up a newprogramming paradigm that will allow for development of a broad varietyof innovative applications, systems, and processes, as well as presentnew challenges for application programmers and database developers.

In a stream computing application, stream operators are connected to oneanother such that data flows from one stream operator to the next (e.g.,over a TCP/IP socket). When a stream operator receives data, it mayperform operations, such as analysis logic, which may change the tupleby adding or subtracting attributes, or updating the values of existingattributes within the tuple. When the analysis logic is complete, a newtuple is then sent to the next stream operator. Scalability is achievedby distributing an application across nodes by creating executables(i.e., processing elements), as well as replicating processing elementson multiple nodes and load balancing among them. Stream operators in astream computing application can be fused together to form a processingelement that is executable. Doing so allows processing elements to sharea common process space, resulting in much faster communication betweenstream operators than is available using inter-process communicationtechniques (e.g., using a TCP/IP socket). Further, processing elementscan be inserted or removed dynamically from an operator graphrepresenting the flow of data through the stream computing application.A particular stream operator may not reside within the same operatingsystem process as other stream operators. In addition, stream operatorsin the same operator graph may be hosted on different nodes, e.g., ondifferent compute nodes or on different cores of a compute node.

Data flows from one stream operator to another in the form of a “tuple.”A tuple is a sequence of one or more attributes associated with anentity. Attributes may be any of a variety of different types, e.g.,integer, float, Boolean, string, etc. The attributes may be ordered. Inaddition to attributes associated with an entity, a tuple may includemetadata, i.e., data about the tuple. A tuple may be extended by addingone or more additional attributes or metadata to it. As used herein,“stream” or “data stream” refers to a sequence of tuples. Generally, astream may be considered a pseudo-infinite sequence of tuples.

Tuples are received and output by stream operators and processingelements. An input tuple corresponding with a particular entity that isreceived by a stream operator or processing element, however, isgenerally not considered to be the same tuple that is output by thestream operator or processing element, even if the output tuplecorresponds with the same entity or data as the input tuple. An outputtuple need not be changed in some way from the input tuple.

Nonetheless, an output tuple may be changed in some way by a streamoperator or processing element. An attribute or metadata may be added,deleted, or modified. For example, a tuple will often have two or moreattributes. A stream operator or processing element may receive thetuple having multiple attributes and output a tuple corresponding withthe input tuple. The stream operator or processing element may onlychange one of the attributes so that all of the attributes of the outputtuple except one are the same as the attributes of the input tuple.

Generally, a particular tuple output by a stream operator or processingelement may not be considered to be the same tuple as a correspondinginput tuple even if the input tuple is not changed by the processingelement. However, to simplify the present description and the claims, anoutput tuple that has the same data attributes or is associated with thesame entity as a corresponding input tuple will be referred to herein asthe same tuple unless the context or an express statement indicatesotherwise.

Stream computing applications handle massive volumes of data that needto be processed efficiently and in real time. For example, a streamcomputing application may continuously ingest and analyze hundreds ofthousands of messages per second and up to petabytes of data per day.Accordingly, each stream operator in a stream computing application maybe required to process a received tuple within fractions of a second.Unless the stream operators are located in the same processing element,it is necessary to use an inter-process communication path each time atuple is sent from one stream operator to another. Inter-processcommunication paths can be a critical resource in a stream computingapplication. According to various embodiments, the available bandwidthon one or more inter-process communication paths may be conserved.Efficient use of inter-process communication bandwidth can speed upprocessing.

An operator graph can be an execution path for a plurality of streamoperators to process a stream of tuples. In addition to streamoperators, the operator graph can refer to an execution path forprocessing elements and the dependent stream operators of the processingelements to process the stream of tuples. Generally, the operator graphcan have a plurality of stream operators that produce a particular endresult, e.g., calculate an average. An operator graph may be a lineararrangement of processing elements and/or operators, or it may includeone or more distinct execution paths, also known as sub-processes,methods, or branches.

A stream computing application may have several “jobs” (i.e., specificapplications) executing in parallel. Each job may be associated with anindividual data flow. These individual data flows may be thought of asseparate operator graphs or portions of the same logical operator graph.In either case, a job or administrator may specify a particular streamof data (e.g., a connection between processing elements or operators inthe operator graph) as “exportable.” A different job may thendynamically connect to the exportable data stream (i.e., import the datastream). This is referred to as a “dynamic connection” because both jobsare currently executing when they begin to share the data stream.

A processing element or stream operator may perform an operation thatemploys a windowing condition. A “window,” as referred to in thisdescription and the claims, is a logical container for tuples receivedby an input port of a stream operator. Conceptually, a stream may beconsidered a pseudo-infinite sequence of tuples. A windowing conditionmay allow for the creation of subsets or groups of tuples within astream, allowing a stream operator to perform an operation on a group oftuples instead of on a single tuple. As an example, an accumulate streamoperator supports windowing by default. However, a stream operator maynot necessarily support windowing by default. A stream operator may,however, be configured to support windowing.

A window may be a tumbling or sliding window. A tumbling window may bespecified by an eviction policy. When the eviction policy for a tumblingwindow is met, the stream operator may execute operator logic on thetuples currently in the window and then empties the window. With respectto a tumbling window, the “conclusion” of a windowing condition, in thisdescription and the claims, may refer to when the eviction policy for atumbling window is met. The eviction policy of a tumbling window may bebased on a count of tuples, a time interval, a delta, or punctuation. Adelta is a difference between an attribute of an oldest tuple and anewest tuple. For example, a windowing condition may compare timestamps.Processing and eviction may be triggered when a time difference exceedsa specified value. A punctuation is a control signal that appearsinterleaved with the tuples in a stream. Punctuation appears in the dataflow and may, for example, notify a stream operator of the grouping oftuples to be processed.

In contrast to a tumbling window, a sliding window does notautomatically flush the window when the window is full. Once a window isfull, a sliding window expels the oldest tuple when a new tuple arrivesto replace it. In this way, a sliding window maintains the size of thewindow. A sliding window may be specified by an eviction policy and atrigger policy. The eviction policy of a sliding window may be based ona count of tuples, a time interval, or an attribute delta. The triggerpolicy specifies when the stream operator executes operator logic on thetuples currently in the window. The trigger policy may be based on acount of tuples, a time interval, or an attribute delta. The evictionand trigger policies are independent of one another. With respect to asliding window, the “conclusion” of a windowing condition, as used inthis description and the claims, may refer to when the trigger conditionof a sliding window is met.

The phrase “windowing conditions,” as used in this description and theclaims, may include the conditions used to describe eviction and triggerpolicies. A stream operator that includes a windowing condition may bereferred to, in this description and the claims, as a windowingoperator. Windowing may be specified in any number of ways. For example,an application programmer may define one or more specific windowingconditions. Additionally, the system may provide a set of windowingconditions.

As used herein, an “intermediate result” is information conveyed by agroup of tuples that may be sent by a stream operator that has performedits operations on accumulated tuples before the trigger policy (for asliding window) or the eviction policy (for a tumbling window) has beentriggered. For example, if a stream operator has a 30-tuple tumblingwindow, and sends out a group of tuples when it has only accumulated 15tuples of data, the group of tuples will contain an intermediate result.An operator may be configured to routinely transmit intermediate resultsaccording to an “intermediate window.” An intermediate window mayestablish how many tuples, or for how long, a stream operator shouldaccumulate tuples before sending out an intermediate result. As is thecase with the standard windows discussed above, an intermediate windowmay be, e.g., time-based or tuple-based, and sliding or tumbling.

Unlike with standard windows, an intermediate window may only have atrigger policy and not an eviction policy. Therefore, the conclusion ofan intermediate window may not include evicting any tuples from memory.For example, at the conclusion of a 2 minute standard tumbling window, astream operator may perform an operation on received tuples, transmitthe results downstream, and clear the received tuples from memory.Alternatively, with a 2 minute intermediate tumbling window, at theconclusion of a window, the stream operator may perform an operation onthe received tuples, transmit results downstream, but may not evict anytuples from memory.

Because intermediate windows do not necessarily have an eviction policy,adding an intermediate window to a stream operator that also has astandard window may not affect the results sent at the conclusion of thestandard window. For example, assume a stream operator is configured toaccumulate 100 tuples and send the sum of the tuples downstream. Alsoassume that an intermediate window of 75 tuples is added to the streamoperator. After aggregating 75 tuples, the stream operator will sum thetuples and send the intermediate results downstream in accordance withits intermediate window, but it will not evict the processed tuples fromits memory. After 25 more tuples are received, the stream operator willsum the 100 tuples and send the intermediate results downstream inaccordance with its standard window. Because the intermediate window didnot have an eviction policy, the same 100 tuples were summed inaccordance with the stream operator's standard window as would have beenif there had been no intermediate window, and the results are unchangedby the inclusion of an intermediate window.

FIG. 1 illustrates one exemplary computing infrastructure 100 that maybe configured to execute a stream computing application, according tosome embodiments. The computing infrastructure 100 includes a managementsystem 105 and two or more compute nodes 110A-110D—i.e., hosts—which arecommunicatively coupled to each other using one or more communicationsnetworks 120. The communications network 120 may include one or moreservers, networks, or databases, and may use a particular communicationprotocol to transfer data between the compute nodes 110A-110D. Adevelopment system 102 may be communicatively coupled with themanagement system 105 and the compute nodes 110 either directly or viathe communications network 120.

The communications network 120 may include a variety of types ofphysical communication channels or “links.” The links may be wired,wireless, optical, or any other suitable media. In addition, thecommunications network 120 may include a variety of network hardware andsoftware for performing routing, switching, and other functions, such asrouters, switches, or bridges. The communications network 120 may bededicated for use by a stream computing application or shared with otherapplications and users. The communications network 120 may be any size.For example, the communications network 120 may include a single localarea network or a wide area network spanning a large geographical area,such as the Internet. The links may provide different levels ofbandwidth or capacity to transfer data at a particular rate. Thebandwidth that a particular link provides may vary depending on avariety of factors, including the type of communication media andwhether particular network hardware or software is functioning correctlyor at full capacity. In addition, the bandwidth that a particular linkprovides to a stream computing application may vary if the link isshared with other applications and users. The available bandwidth mayvary depending on the load placed on the link by the other applicationsand users. The bandwidth that a particular link provides may also varydepending on a temporal factor, such as time of day, day of week, day ofmonth, or season.

FIG. 2 is a more detailed view of a compute node 110, which may be thesame as one of the compute nodes 110A-110D of FIG. 1, according tovarious embodiments. The compute node 110 may include, withoutlimitation, one or more processors (CPUs) 205, a network interface 215,an interconnect 220, a memory 225, and a storage 230. The compute node110 may also include an I/O device interface 210 used to connect I/Odevices 212, e.g., keyboard, display, and mouse devices, to the computenode 110.

Each CPU 205 retrieves and executes programming instructions stored inthe memory 225 or storage 230. Similarly, the CPU 205 stores andretrieves application data residing in the memory 225. The interconnect220 is used to transmit programming instructions and application databetween each CPU 205, I/O device interface 210, storage 230, networkinterface 215, and memory 225. The interconnect 220 may be one or morebusses. The CPUs 205 may be a single CPU, multiple CPUs, or a single CPUhaving multiple processing cores in various embodiments. In oneembodiment, a processor 205 may be a digital signal processor (DSP). Oneor more processing elements 235 (described below) may be stored in thememory 225. A processing element 235 may include one or more streamoperators 240 (described below). In one embodiment, a processing element235 is assigned to be executed by only one CPU 205, although in otherembodiments the stream operators 240 of a processing element 235 mayinclude one or more threads that are executed on two or more CPUs 205.The memory 225 is generally included to be representative of a randomaccess memory, e.g., Static Random Access Memory (SRAM), Dynamic RandomAccess Memory (DRAM), or Flash. The storage 230 is generally included tobe representative of a non-volatile memory, such as a hard disk drive,solid state device (SSD), or removable memory cards, optical storage,flash memory devices, network attached storage (NAS), or connections tostorage area network (SAN) devices, or other devices that may storenon-volatile data. The network interface 215 is configured to transmitdata via the communications network 120.

A stream computing application may include one or more stream operators240 that may be compiled into a “processing element” container 235. Twoor more processing elements 235 may run on the same memory 225, eachprocessing element having one or more stream operators 240. Each streamoperator 240 may include a portion of code that processes tuples flowinginto a processing element and outputs tuples to other stream operators240 in the same processing element, in other processing elements, or inboth the same and other processing elements in a stream computingapplication. Processing elements 235 may pass tuples to other processingelements that are on the same compute node 110 or on other compute nodesthat are accessible via communications network 120. For example, aprocessing element 235 on compute node 110A may output tuples to aprocessing element 235 on compute node 110B.

The storage 230 may include a buffer 260. Although shown as being instorage, the buffer 260 may be located in the memory 225 of the computenode 110 or in a combination of both memories. Moreover, storage 230 mayinclude storage space that is external to the compute node 110, such asin a cloud.

The compute node 110 may include one or more operating systems 262. Anoperating system 262 may be stored partially in memory 225 and partiallyin storage 230. Alternatively, an operating system may be storedentirely in memory 225 or entirely in storage 230. The operating systemprovides an interface between various hardware resources, including theCPU 205, and processing elements and other components of the streamcomputing application. In addition, an operating system provides commonservices for application programs, such as providing a time function.

FIG. 3 is a more detailed view of the management system 105 of FIG. 1according to some embodiments. The management system 105 may include,without limitation, one or more processors (CPUs) 305, a networkinterface 315, an interconnect 320, a memory 325, and a storage 330. Themanagement system 105 may also include an I/O device interface 310connecting I/O devices 312, e.g., keyboard, display, and mouse devices,to the management system 105.

Each CPU 305 retrieves and executes programming instructions stored inthe memory 325 or storage 330. Similarly, each CPU 305 stores andretrieves application data residing in the memory 325 or storage 330.The interconnect 320 is used to move data, such as programminginstructions and application data, between the CPU 305, I/O deviceinterface 310, storage unit 330, network interface 315, and memory 325.The interconnect 320 may be one or more busses. The CPUs 305 may be asingle CPU, multiple CPUs, or a single CPU having multiple processingcores in various embodiments. In one embodiment, a processor 305 may bea DSP. Memory 325 is generally included to be representative of a randomaccess memory, e.g., SRAM, DRAM, or Flash. The storage 330 is generallyincluded to be representative of a non-volatile memory, such as a harddisk drive, solid state device (SSD), removable memory cards, opticalstorage, Flash memory devices, network attached storage (NAS),connections to storage area-network (SAN) devices, or the cloud. Thenetwork interface 315 is configured to transmit data via thecommunications network 120.

The memory 325 may store a stream manager 134. Additionally, the storage330 may store an operator graph 132. The operator graph 132 may definehow tuples are routed to processing elements 235 (FIG. 2) forprocessing.

The management system 105 may include one or more operating systems 332.An operating system 332 may be stored partially in memory 325 andpartially in storage 330. Alternatively, an operating system may bestored entirely in memory 325 or entirely in storage 330. The operatingsystem provides an interface between various hardware resources,including the CPU 305, and processing elements and other components ofthe stream computing application. In addition, an operating systemprovides common services for application programs, such as providing atime function.

FIG. 4 is a more detailed view of the development system 102 of FIG. 1according to some embodiments. The development system 102 may include,without limitation, one or more processors (CPUs) 405, a networkinterface 415, an interconnect 420, a memory 425, and storage 430. Thedevelopment system 102 may also include an I/O device interface 410connecting I/O devices 412, e.g., keyboard, display, and mouse devices,to the development system 102.

Each CPU 405 retrieves and executes programming instructions stored inthe memory 425 or storage 430. Similarly, each CPU 405 stores andretrieves application data residing in the memory 425 or storage 430.The interconnect 420 is used to move data, such as programminginstructions and application data, between the CPU 405, I/O deviceinterface 410, storage unit 430, network interface 415, and memory 425.The interconnect 420 may be one or more busses. The CPUs 405 may be asingle CPU, multiple CPUs, or a single CPU having multiple processingcores in various embodiments. In one embodiment, a processor 405 may bea DSP. Memory 425 is generally included to be representative of a randomaccess memory, e.g., SRAM, DRAM, or Flash. The storage 430 is generallyincluded to be representative of a non-volatile memory, such as a harddisk drive, solid state device (SSD), removable memory cards, opticalstorage, flash memory devices, network attached storage (NAS),connections to storage area-network (SAN) devices, or to the cloud. Thenetwork interface 415 is configured to transmit data via thecommunications network 120.

The development system 102 may include one or more operating systems432. An operating system 432 may be stored partially in memory 425 andpartially in storage 430. Alternatively, an operating system may bestored entirely in memory 425 or entirely in storage 430. The operatingsystem provides an interface between various hardware resources,including the CPU 405, and processing elements and other components ofthe stream computing application. In addition, an operating systemprovides common services for application programs, such as providing atime function.

The memory 425 may store a compiler 136. The compiler 136 compilesmodules, which include source code or statements, into the object code,which includes machine instructions that execute on a processor. In oneembodiment, the compiler 136 may translate the modules into anintermediate form before translating the intermediate form into objectcode. The compiler 136 may output a set of deployable artifacts that mayinclude a set of processing elements and an application descriptionlanguage file (ADL file), which is a configuration file that describesthe stream computing application. In some embodiments, the compiler 136may be a just-in-time compiler that executes as part of an interpreter.In other embodiments, the compiler 136 may be an optimizing compiler. Invarious embodiments, the compiler 136 may perform peepholeoptimizations, local optimizations, loop optimizations, inter-proceduralor whole-program optimizations, machine code optimizations, or any otheroptimizations that reduce the amount of time required to execute theobject code, to reduce the amount of memory required to execute theobject code, or both. The output of the compiler 136 may be representedby an operator graph, e.g., the operator graph 132 of FIG. 1.

The compiler 136 may also provide the application administrator with theability to optimize performance through profile-driven fusionoptimization. Fusing operators may improve performance by reducing thenumber of calls to a transport. While fusing stream operators mayprovide faster communication between operators than is available usinginter-process communication techniques, any decision to fuse operatorsrequires balancing the benefits of distributing processing acrossmultiple compute nodes with the benefit of faster inter-operatorcommunications. The compiler 136 may automate the fusion process todetermine how to best fuse the operators to be hosted by one or moreprocessing elements, while respecting user-specified constraints. Thismay be a two-step process, including compiling the application in aprofiling mode and running the application, then re-compiling and usingthe optimizer during this subsequent compilation. The end result may,however, be a compiler-supplied deployable application with an optimizedapplication configuration.

FIG. 5 illustrates an exemplary operator graph 500 for a streamcomputing application beginning from one or more sources 502 through toone or more sinks 504, 506, according to some embodiments. This flowfrom source to sink may also be generally referred to herein as anexecution path. In addition, a flow from one processing element toanother may be referred to as an execution path in various contexts.Although FIG. 5 is abstracted to show connected processing elementsPE1-PE10, the operator graph 500 may include data flows between streamoperators 240 (FIG. 2) within the same or different processing elements.Typically, processing elements, such as processing element 235 (FIG. 2),receive tuples from the stream as well as output tuples into the stream(except for a sink—where the stream terminates, or a source—where thestream begins). While the operator graph 500 includes a relatively smallnumber of components, an operator graph may be much more complex and mayinclude many individual operator graphs that may be statically ordynamically linked together.

The example operator graph shown in FIG. 5 includes ten processingelements (labeled as PE1-PE10) running on the compute nodes 110A-110D. Aprocessing element may include one or more stream operators fusedtogether to form an independently running process with its own processID (PID) and memory space. In cases where two (or more) processingelements are running independently, inter-process communication mayoccur using a “transport,” e.g., a network socket, a TCP/IP socket, orshared memory. Inter-process communication paths used for inter-processcommunications can be a critical resource in a stream computingapplication. However, when stream operators are fused together, thefused stream operators can use more rapid communication techniques forpassing tuples among stream operators in each processing element.

The operator graph 500 begins at a source 502 and ends at a sink 504,506. Compute node 110A includes the processing elements PE1, PE2, andPE3. Source 502 flows into the processing element PE1, which in turnoutputs tuples that are received by PE2 and PE3. For example, PE1 maysplit data attributes received in a tuple and pass some data attributesin a new tuple to PE2, while passing other data attributes in anothernew tuple to PE3. As a second example, PE1 may pass some received tuplesto PE2 while passing other tuples to PE3. Tuples that flow to PE2 areprocessed by the stream operators contained in PE2, and the resultingtuples are then output to PE4 on compute node 110B. Likewise, the tuplesoutput by PE4 flow to PE6 before being transmitted to a sink 504.Similarly, tuples flowing from PE3 to PE5 also reach PE6 and are sent toa sink 504. Thus, PE6 could be configured to perform a join operation,combining tuples received from PE4 and PE5, before sending the data tothe sink 504. This example operator graph also shows tuples flowing fromPE3 to PE7 on compute node 110C, which itself shows tuples flowing toPE8 and looping back to PE7. Tuples output from PE8 flow to PE9 oncompute node 110D, which in turn outputs tuples to be processed byoperators in PE10 before being sent to a sink 506.

The tuple received by a particular processing element 235 (FIG. 2) isgenerally not considered to be the same tuple that is output downstream.Typically, the output tuple is changed in some way. An attribute ormetadata may be added, deleted, or changed. However, it is not requiredthat the output tuple be changed in some way. Generally, a particulartuple output by a processing element may not be considered to be thesame tuple as a corresponding input tuple even if the input tuple is notchanged by the processing element. However, to simplify the presentdescription and the claims, an output tuple that has the same dataattributes as a corresponding input tuple may be referred to herein asthe same tuple.

Processing elements 235 (FIG. 2) may be configured to receive or outputtuples in various formats, e.g., the processing elements or streamoperators could exchange data marked up as XML documents. Furthermore,each stream operator 240 within a processing element 235 may beconfigured to carry out any form of data processing functions onreceived tuples, including, for example, writing to database tables orperforming other database operations such as data joins, splits, reads,etc., as well as performing other data analytic functions or operations.

The stream manager 134 of FIG. 1 may be configured to monitor a streamcomputing application running on compute nodes, e.g., compute nodes110A-110D, as well as to change the deployment of an operator graph,e.g., operator graph 132. The stream manager 134 may move processingelements from one compute node 110 to another, for example, to managethe processing loads of the compute nodes 110A-110D in the computinginfrastructure 100. Further, stream manager 134 may control the streamcomputing application by inserting, removing, fusing, un-fusing, orotherwise modifying the processing elements and stream operators (orwhat tuples flow to the processing elements) running on the computenodes 110A-110D.

Because a processing element may be a collection of fused streamoperators, it is equally correct to describe the operator graph as oneor more execution paths between specific stream operators, which mayinclude execution paths to different stream operators within the sameprocessing element. FIG. 5 illustrates execution paths betweenprocessing elements for the sake of clarity.

FIGS. 6A and 6B illustrate an example of a stream computing applicationin which illustrative embodiments of the present disclosure may beimplemented. The stream computing application of FIGS. 6A and 6B is asimple application used for illustrative purposes. Embodiments of thepresent disclosure may be implemented on stream computing applicationswith more complexity than shown in FIGS. 6A and 6B. In this example, theresults of an election may be tracked in real time.

Referring now specifically to FIG. 6A, shown is an example of anoperator graph of a stream computing application with a first job 602, asource 603, and a sink 605. The first job 602 may comprise two streamoperators OP61-62. The first stream operator OP61 may import vote countscorresponding to a plurality of polling places from one or more sources603. The first stream operator OP61 may accumulate the data it receivesfrom the source 603 according to its window. When the eviction policy istriggered, the first stream operator OP61 may compute the sum of thenumber of votes for each of the candidates and transmit the sums in oneor more tuples to the second stream operator OP62. The second streamoperator OP62 may process the results so that they are in a form thatcan be used by non-stream computing applications, and transmit them tothe sink 605.

Referring now to FIG. 6B, shown is an example table 610 of tuple dataaccumulated by the first stream operator OP61 of FIG. 6A, in accordancewith embodiments of the present disclosure. The table 610 is a visualrepresentation of accumulated tuples used for an illustrative purpose.It does not necessarily show the exact mechanism or process by which astream operator may accumulate and store tuples or data. The table 610may consist of three columns 612A-C and ten rows 614A-J. Each row maycorrespond to a different tuple received by the first stream operatorOP61 from one or more source 603. Each column may store the attributesof the received tuples. For example, the first column 612A may store atuple ID. The tuple ID may be a number that identifies which pollingplace sent the data. The second column 612B may store the number ofvotes that a first candidate received at each polling place. The thirdcolumn 612C may store the number of votes that a second candidatereceived at each polling place.

For example, the first tuple received during the windowing period by thefirst stream operator OP61 may be seen in the first row 614A. The tuplemay have the tuple ID of ‘1,’ shown in the first column 612A, indicatingthat the tuple was sent by a first polling place. As seen in the secondcolumn 612B, the first candidate may have received four votes at thefirst polling place, and, as seen in the third column 612C, the secondcandidate may have received eight votes at the first polling place. Thefirst stream operator OP61 may accumulate tuples in this fashion untilits eviction policy is triggered. In the example shown in FIG. 6B, thefirst stream operator OP61 has accumulated ten tuples of datacorresponding to ten polling places.

Referring now to FIG. 7, shown is a flowchart illustrating a method 700for transmitting intermediate tuples, in accordance with embodiments ofthe present disclosure. In some embodiments, the method 700 may beperformed by one or more stream operators. In other embodiments, themethod 700 may be performed by a combination of one or more streamoperators and a stream manager 134 (shown in FIG. 1). The method 700 maybegin at operation 702, where a stream of tuples is received at a firststream operator.

The first stream operator may accumulate the stream of tuples accordingto its window. When the first stream operator's eviction policy istriggered, it may perform an operation on the received tuples and outputone or more tuples to a second stream operator. The first streamoperator may have any window supported by the stream computingapplication. For example, in some embodiments the first stream operatormay have a tumbling window, while in other embodiments the first streamoperator may use sliding windows. In either case, the window may betime-based or tuple-based.

At decision block 704, the first stream operator may determine whether afirst condition has occurred. A first condition is a condition that,when it occurs, indicates that intermediate results are requested andthat the first stream operator should transmit a group of tuplescontaining the intermediate results to the second stream operator. Thereare a number of ways that the first stream operator may determine that afirst condition has occurred and that it should send intermediateresults.

In some embodiments, the first stream operator may determine that afirst condition has occurred when the first stream operator hasaccumulated enough data to perform its operations and, as a result, maysend intermediate results before its eviction policy has been triggered.For example, the first stream operator may be configured to accumulatetuples according to a time-based tumbling window and, when the evictionpolicy triggers, calculate the average from the accumulated tuples. Thefirst stream operator may determine that, even though it is only onehalf of the way through its window, a first condition has occurredbecause the first stream operator has accumulated enough data to performits operations.

The first stream operator may determine that it has accumulated enoughtuples by comparing the number of accumulated tuples to a threshold. Thethreshold may be configured by a user, or it may be based on historicalinformation about the stream operator. For example, if the first streamoperator has a 5 minute window, during which time it usually accumulates50 tuples, the first stream operator (or the stream manager) may set athreshold of 100 tuples. If the first stream operator receives 100tuples before the eviction policy triggers, it may calculate the averageof the 100 tuples and transmit the intermediate results downstream. Thefirst stream operator may then continue to accumulate tuples and, whenthe eviction policy triggers, perform an operation on the accumulatedtuples (e.g., the original 100 tuples plus however many more have beenreceived since the intermediate results were sent) and transmit thenormal results downstream.

In some embodiments, the first stream operator may determine that afirst condition has occurred when its memory becomes full. For example,the first stream operator may have a time-based tumbling window of,e.g., 10 minutes. The first stream operator determine that its memory isfull and it is unable to accumulate any more tuples after only 5 minutesof aggregating tuples. In lieu of dropping the tuples it receives forthe next 5 minutes until its eviction policy is triggered, or replacingwindowed tuples already in memory with newer tuples, the first streamoperator may determine that a first condition has occurred (memory hasfilled) and may perform an operation on the received tuples and transmitthe intermediate results downstream. The first stream operator may then,in some embodiments, flush the window. In some embodiments, the firststream operator may not reset the window and may, instead, continue toreceive new tuples and, for every new tuple received, evict the oldesttuple from its memory. In some embodiments, the first stream operatormay drop the newly received tuples.

In some embodiments, the first condition may be that the second streamoperator has directly requested the intermediate results. For example,in some embodiments, the second stream operator may join informationfrom the first stream operator and a third stream operator. If the thirdstream operator has transmitted tuples to the second stream operatorthat indicates that an event may be happening, it may be important thatthe second stream operator respond in real-time. This may necessitatereceiving information from the first stream operator immediately. If thefirst stream operator uses time-based windows, the second streamoperator may wait until the first stream operator's eviction policy istriggered at the end of its window, react without updated information,or request intermediate results.

For example, in a pool-type nuclear reactor, a core of radioactivematerial is immersed in an open pool of water that acts, in part, tocool the core. If the core's temperature increases too much, the warmerpool water may be partially replaced by cool water. A first streamoperator may monitor the temperature of the cooling water. Every 30seconds, the first stream operator may take a temperature reading and,every 5 minutes, it may average the 10 readings and transmits theaverage to a second stream operator. A third stream operator may monitorthe temperature of the core and transmit the temperature to the secondstream operator. The second stream operator may, based on theinformation it receives from the first and third stream operators,determine whether to replace some of the pool water with the coolingwater. Making that determination may require up-to-date informationregarding the temperature of the cooling water and of the core. If thethird stream operator sends information to the second stream operatorthat indicates that the core is getting too hot, the second streamoperator may determine that cooling water needs to be added to the poolimmediately. If the first stream operator's eviction policy will nottrigger for another three minutes, the second stream operator may send arequest for intermediate results so that it can accurately determine howmuch cool water to add to the pool.

In some embodiments, it may be determined that a first condition hasoccurred when the second stream operator needs the first stream operatorto send intermediate results in order for the second stream operator toperform its operations. For example, assume that a first tuple from adata stream is sent to two stream operators so that two operations maybe performed on that tuple in parallel. A first stream operator mayperform a first operation on the first tuple and output a second tuple,and a second stream operator may perform a second operation on the firsttuple and output a third tuple. In some circumstances, it may bebeneficial to join the second and third tuples together. A third streamoperator may be used to synchronize tuples from two or more streams. Thethird stream operator may work even if the first and second operatorsperform their operations, and therefore output tuples, at differentrates by holding on to a tuple received at one port until acorresponding tuple is received at a second port. The third streamoperator may be used to rejoin the tuples and output a single tuple ofdata that incorporates the operations performed by the first and secondstream operators.

If the first and second stream operators have different windowingconditions, the third stream operator may receive several tuples fromthe first stream operator before receiving one from the second streamoperator. Because the third stream operators holds on to tuples until itreceives a corresponding tuple from another data stream, the thirdstream operator's memory may begin to fill up. For example, if the firststream operator outputs a tuple every 1 minute, and the second streamoperator outputs a tuple every 5 minutes, the third stream operatorwill, at the end of 5 minutes, have 4 extra tuples stored in memorywaiting to be matched with a corresponding tuple. After 10 minutes, thethird stream operator will have 8 tuples saved in memory, and so on.Instead of keeping data in memory, allowing it to grow older whilewaiting to be processed, it may be determined that the third streamoperator needs intermediate results from the second stream operator inorder to timely process its data and to keep its memory from filling.Accordingly, the second stream operator may send intermediate results tothe third stream operator whenever the first stream operator sends itsresults.

In some embodiments, it may be determined that a first condition hasoccurred when the results being output by the first stream operator arechanging. A first condition may be considered present if the resultoutput by the first stream operator deviates from an average by morethan a threshold, or if the results lies outside of a confidenceinterval determined from the historical results sent by the first streamoperator.

For example, the first stream operator may be configured to accumulatetuples for 10 minutes before calculating an average from the tuples.Considering the pool-type nuclear reactor discussed herein, the averagemay correspond to, e.g., the temperature of the core. For a few hours,the average of the accumulated tuples may be calculated to be around 150degrees Celsius, with little deviation. The stream computing applicationfor the nuclear reactor may be configured so that a first condition hasoccurred if a result deviates from the norm by more than a threshold(e.g., a threshold of 50 degrees Celsius). If the second stream operatorreceives a tuple from the third stream operator that suggests that thetemperature averaged 215 degrees Celsius for the last 10 minutes,thereby surpassing the threshold, the first stream operator may sendintermediate results every 30 seconds so that the second stream operatorcan determine whether the core's temperature is steadily rising, whichmay be dangerous, or if the result was an outlier or inaccuratelymeasured.

As another example, it may be determined that a first condition hasoccurred if a result sent by a stream operator is outside of aconfidence interval. For example, again looking at the pool-type nuclearreactor, the core's temperature readings may consistently lie between134 degrees Celsius and 158 degrees Celsius, with a mean of 150 degreesCelsius. Based on this historical data, a confidence interval may becreated that determines a normal operating range of temperatures for thecore to be between 130 degrees Celsius and 160 degrees Celsius. If thesecond stream operator receives a temperature reading from the thirdstream operator that lies outside of this range, the third streamoperator may begin to send intermediate results every 30 seconds inaddition to the normal results that it sends every 10 minutes.

After determining that a first condition has occurred per decision block704, the first stream operator may determine whether a second conditionexists at decision block 706. In some embodiments, the presence of asecond condition may indicate that, regardless of whether a firstcondition has occurred, the first stream operator should not sendintermediate results. In some embodiments, a second condition mayindicate that the first stream operator is unable to perform itsoperations on the received tuples. This may be, for example, because thefirst stream operator lacks available system resources to perform itsoperations. It may also be because the first stream operator has notreceived enough tuples to perform its operations. In some embodiments, asecond condition may indicate that the second stream operator is unableto receive intermediate tuples. In some embodiments, the stream manager,instead of the first stream operator, may determine whether a secondcondition exists. In other embodiments, a different stream operator(e.g., the second stream operator) or processing element may determinethat a second condition exists.

For example, the first stream operator may monitor available systemresources when determining whether a second condition exists. Theavailable system resources may include, e.g., available memory and CPUutilization. The available system resources may correspond to the firststream operator, the second stream operator, or any other streamoperators in the operator graph. For example, if the second streamoperator does not have available memory to store additional data, thefirst stream operator may determine that the second stream operator isnot capable of receiving and/or processing the intermediate results atthat time. As another example, if the CPU utilization of the firststream operator is very high, the first stream operator may determinethat it is not capable of performing any operations on the tuples thatit has already received and, therefore, may not transmit intermediateresults.

In some embodiments, determining whether a second condition existsincludes the first stream operator determining whether it has enoughdata to perform its operations at decision block 706. For example, afirst stream operator may be configured to receive a plurality oftuples, each tuple having a first attribute with a number in it, and tocalculate the mean and standard deviation of those tuples. If, when theintermediate results are requested, the first stream operator does nothave any accumulated tuples, it will be unable to calculate the mean andstandard deviation. Therefore, the first stream operator may determinethat a second condition exists and that it cannot send intermediateresults, even if a first condition has occurred.

In some embodiments, the first stream operator may be configured todetermine whether the intermediate results will be meaningful accordingto a predetermined set of criteria. If the results will not bemeaningful, the first stream operator may determine that a secondcondition exists and it will not transmit intermediate results, even ifthey are requested by the second stream operator. For example, againtake the case of an operator configured to find the mean and standarddeviation of a set of data. If the intermediate results are requestedwhen the operator has two tuples of data accumulated, it may be possibleto calculate the mean and standard deviation. However, the mean andstandard deviation of a set of two numbers may be, in somecircumstances, low value information because the mean and standarddeviation calculation would be highly susceptible to outliers.Accordingly, the first stream operator may, in some embodiments,determine that the intermediate results are not meaningful and shouldnot be sent even if they are requested.

In some embodiments, determining how many tuples are needed before datais considered meaningful and intermediate results should be sent can beconfigured by a user or established by an administrator of the streamcomputing application using, e.g., known statistical analysistechniques. The administrator may establish a threshold number oftuples. The threshold may establish the minimum acceptable number ofaccumulated tuples for a stream operator to output intermediate results.If the stream operator has accumulated a greater number of tuples thanthe threshold, it may be able to send intermediate results. Otherwise, asecond condition may exist and the stream operator may not be able tooutput intermediate results. For example, the administrator maydetermine that there must be at least 20 tuples of data accumulated byan operator that calculates the mean or standard deviation for theresults to be considered meaningful. Accordingly, if a stream operatoris configured to calculate the standard deviation of received tuple, andit has accumulated 15 tuples when a request for intermediate results ismade, the stream operator may determine that a second condition existsand that it may not transmit the intermediate results.

If, at decision block 706, the first stream operator determines that asecond condition exists and that it should not transmit intermediateresults, the method 700 may end. If, however, the first stream operatordetermines that a second condition is not present and that it shouldsend intermediate results, the first stream operator may perform one ormore operations on the tuples that it has received per operation 708. Atoperation 710, the first stream operator may transmit a group of one ormore tuples with the intermediate results to the second stream operator,and the method 700 may end. In some embodiments, the first streamoperator's windows will not be reset after the intermediate results aretransmitted. In other embodiments, the first stream operator's windowmay be reset when the intermediate results are sent.

In some embodiments, the first stream operator may determine thatintermediate results should be periodically sent according to anintermediate window. In some embodiments, the intermediate window may bedynamically reconfigured. For example, if a second stream operatorrepeatedly requests intermediate results every 2 minutes, and the firststream operator's windowing conditions establish a 5 minute window, thestream manager may create an intermediate window for the first streamoperator. The intermediate window may, in this case, cause the firststream operator to transmit intermediate results every 2 minutes. Unlikethe first stream operator's standard window, in some embodiments, theintermediate window may not include an eviction policy that clears thefirst stream operator's memory.

In some embodiments, the stream manager may determine that theintermediate window should replace the standard window, in which casethe intermediate window may be modified to include an eviction policy.This may be done if, e.g., the stream manager determines that theintermediate window is providing information that is sufficientlyaccurate so that there is a low probability of the downstream operatorsreceiving bad information (e.g., information that causes their resultsto be different from what is expected or correct). For example, a streamoperator may be configured to calculate the average of a group ofreceived tuples. If the intermediate results sent in accordance with theintermediate window are consistently close to (e.g., within a thresholdof) the results sent in accordance with the standard window, the streammanager may determine that the intermediate window is providingmeaningful results, and the intermediate window may replace the standardwindow.

In some embodiments, the intermediate results may be tuple-based even ifthe window is time-based. For example, a first stream operator may havea window that accumulates tuples for 5 minutes before performing anoperation on the tuples and transmitting results to a second streamoperator. The second stream operator may request intermediate results besent for every 20 tuples received by the first stream operator. Thestream manager may then create an intermediate window for the firststream operator that causes the first stream operator to sendintermediate results every 20 tuples, even though the standard window istime-based. In other embodiments, the reverse may be true; the streammanager may create an intermediate window for the first stream operatorthat is time-based, even if the standard window is tuple-based.

In some embodiments, the group of tuples sent as intermediate resultsmay contain additional attributes not normally sent. These additionalattributes may include, e.g., a number corresponding to the percentageof window completion at the time of transmittal. For example, if a firststream operator has a window that instructs aggregating 30 tuples, andintermediate results are requested and sent when only 15 tuples havebeen received by the first stream operator during the existence of thewindow, the group of tuples sent by the first stream operator mayinclude an attribute that informs the second stream operator that 50% ofthe window was complete when the intermediate results were sent. Theadditional attributes may also include a confidence level in theaccuracy or usability of the intermediate results, as well as the totalnumber of tuples accumulated by the first stream operator when theintermediate results were transmitted.

Applying the method 700 to the example discussed in reference to FIGS.6A and 6B, a first stream operator OP61 may be configured using atuple-based window to accumulate voting data from a source. The windowmay cause the first stream operator OP61 to accumulate the voting datauntil it has 30 tuples of data stored in its memory, one for eachpolling place within the precinct where the election is taking place.Once all the polling places in the precinct have reported their results,the first stream operator OP61 may sum the votes received by eachcandidate and send the results to the second stream operator OP62, wherethe results are formatted such that a user (e.g., a local newspaper) canimport the results into, e.g., their website. The properly formattedresults may be sent to the sink 605 and provided to the user.

The user may decide that it wants to host a discussion page on itswebsite, where the user's customers may talk about the elections goingon, including the local election that is being monitored by the streamscomputing application. The user may believe that the discussion pagewill be better served if, instead of waiting until all polling placeshave reported before providing a vote count to their customers,customers could get updates as they are known. The user may requestintermediate results from the first stream operator be sent out so thatthe user can update his website with up-to-date information. Asdiscussed herein, the intermediate results may be sent using atuple-based intermediate window (e.g., every time a polling placesubmits its vote count), a time based intermediate window (e.g., every 5minutes), or any other type of window that the stream computingapplication can utilize.

The first stream operator OP61 may, in response to the request, andafter determining that no second condition exists, calculate the sum foreach candidate and transmit a group of tuples to the second streamoperator OP62. The group of tuples may include additional attributes,such as the percentage of polling places that have reported their votesor a list of which polling places have reported their votes. The secondstream operator OP62 may then convert the tuples it receives into aformat more useful to the user, such as java or html, and send it to theuser through the sink 605, and the process may end.

As discussed in more detail herein, it is contemplated that some or allof the operations of some of the embodiments of methods described hereinmay be performed in alternative orders or may not be performed at all;furthermore, multiple operations may occur at the same time or as aninternal part of a larger process.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the variousembodiments. As used herein, the singular forms “a,” “an,” and “the” areintended to include the plural forms as well, unless the context clearlyindicates otherwise. It will be further understood that the terms“includes” and/or “including,” when used in this specification, specifythe presence of the stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof. In the previous detaileddescription of exemplary embodiments of the various embodiments,reference was made to the accompanying drawings (where like numbersrepresent like elements), which form a part hereof, and in which isshown by way of illustration specific exemplary embodiments in which thevarious embodiments may be practiced. These embodiments were describedin sufficient detail to enable those skilled in the art to practice theembodiments, but other embodiments may be used and logical, mechanical,electrical, and other changes may be made without departing from thescope of the various embodiments. In the previous description, numerousspecific details were set forth to provide a thorough understanding thevarious embodiments. But, the various embodiments may be practicedwithout these specific details. In other instances, well-known circuits,structures, and techniques have not been shown in detail in order not toobscure embodiments.

Different instances of the word “embodiment” as used within thisspecification do not necessarily refer to the same embodiment, but theymay. Any data and data structures illustrated or described herein areexamples only, and in other embodiments, different amounts of data,types of data, fields, numbers and types of fields, field names, numbersand types of rows, records, entries, or organizations of data may beused. In addition, any data may be combined with logic, so that aseparate data structure may not be necessary. The previous detaileddescription is, therefore, not to be taken in a limiting sense.

The descriptions of the various embodiments of the present disclosurehave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

Although the present invention has been described in terms of specificembodiments, it is anticipated that alterations and modification thereofwill become apparent to the skilled in the art. Therefore, it isintended that the following claims be interpreted as covering all suchalterations and modifications as fall within the true spirit and scopeof the invention.

What is claimed is:
 1. A system for processing a stream of tuplescomprising: a plurality of processing elements to receive a stream oftuples, each processing element including one or more stream operators,wherein one or more of the stream operators include code configured tooutput tuples to one or more other stream operators; two or moreprocessors; and a memory containing an application that, when executed,causes at least one of the two or more processors to: receive the streamof tuples at a first stream operator, the first stream operator beingconfigured to accumulate the stream of tuples according to a first setof windowing conditions, the first set of windowing conditions beinginternal to the first stream operator, the first set of windowingconditions including an operation to be performed on received tuples andan eviction policy, wherein the first stream operator is furtherconfigured to output a first group of tuples to a second stream operatorwhen the eviction policy triggers; determine that a first condition hasoccurred, the first condition indicating that an intermediate group oftuples are requested before the eviction policy triggers, theintermediate group of tuples conveying intermediate results; determine,in response to determining that the first condition has occurred, that asecond condition is not present, the second condition indicating thatthe first stream operator should not output the intermediate group oftuples before the eviction policy triggers; perform, in response todetermining that the second condition is not present, by the firststream operator, the operation on the received tuples before theeviction policy triggers; and transmit, by the first stream operator, asecond group of tuples to the second stream operator before the evictionpolicy triggers.
 2. A computer program product for processing a streamof tuples, the computer program product comprising a computer readablestorage medium having program code embodied therein, the program codecomprising computer readable program code configured to: receive astream of tuples to be processed by a plurality of processing elements,each processing element including one or more stream operators, whereinone or more of the stream operators include code configured to outputtuples to one or more other stream operators; receive the stream oftuples at a first stream operator, the first stream operator beingconfigured to accumulate the stream of tuples according to a first setof windowing conditions, the first set of windowing conditions beinginternal to the first stream operator, the first set of windowingconditions including an operation to be performed on received tuples andan eviction policy, wherein the first stream operator is furtherconfigured to output a first group of tuples to a second stream operatorwhen the eviction policy triggers; determine that a first condition hasoccurred, the first condition indicating that an intermediate group oftuples are requested before the eviction policy triggers, theintermediate group of tuples conveying intermediate results; determine,in response to determining that the first condition has occurred, that asecond condition is not present, the second condition indicating thatthe first stream operator should not output the intermediate group oftuples before the eviction policy triggers; perform, in response todetermining that the second condition is not present, by the firststream operator, the operation on the received tuples before theeviction policy triggers; and transmit, by the first stream operator, asecond group of tuples to the second stream operator before the evictionpolicy triggers.